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DETAILED ACTION 
Prosecution History 

Application was filed on 1 February 1999 (paper #1). 

A First Office Action rejected Claims 1-19 on 29 September 2001 (paper # 19). 

Amendment A Cancelled claims 1-19 on 2 January 2002 (paper # 20). 

A Final Rejection rejected claims 20-35 on 7 March 2002 (paper # 21). 

Applicant filed a response on 20 May 2002 (paper # 22) and Amendment B on 7 
May 2002 (paper #23). 

The Examiner Withdrew finality of previous rejection and rejected claims 20-25 
on 30 May 2002 (paper #24). 

By Amendment C, applicant amended claims 20, 28, 29 and cancelled claim 24, 
on 30 August 2002 (paper #25). 

The Examiner issued a Final Rejection of claims 20-23, 25-35 on 19 November 
2002 (paper #26). 

Applicant filed an After Final Amendment D on 2 April 2003 (paper #27) and 
requested reconsideration. Amendment D was not entered. 

The Office mailed an Advisory Action 18 April 2003 (paper # 28). 

Applicant filed a Notice of Appeal 28 April 2003 (paper # 29). 

Applicant filed a Request for Continuing Examination 28 May 2003 (paper # 30). 

The Examiner rejected claims 20-23 and 25-35 on 13 August 2003 (paper # 31). 

Applicant sent Amendment E on 13 November 2003 (paper # 32). 
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The Office mailed a Notice of Non-compliance on 13 November 2003 (paper # 
33). The Notice informed Applicant that Amendment E is inconsistent with 27 C.F.R. 
1.121 in that it did not provide a complete listing of all the claims, including claim 24. 

Applicant faxed a Substitute Response on 1 5 December 2003. This paper was 
not entered because it failed to provide a full listing of the claims, including claim 24,as 
required. The Substitute Response introduced new errors. Paragraph 1 on page 1, "In 
response to the Final Office Action mailed November 18, 2003..." should read 

• "In response to the Office Action mailed August 13, 2003..." since the Office Action of that 
date (paper #31) was a non-final rejection, or 

• "In response to the Notice of Non-Compliant Amendment mailed November 18, 2003..." 

The Examiner attempted several times to reach applicant's attorney by telephone 
to inform him of the errors in his Substitute Response. The efforts were unsuccessful. 

The present Office Action is a response to Substitute Response of 15 December 
2003, which cancelled claim 28. Claim 24 was cancelled in Amendment B of 30 August 
2002 and therefore does not affect an Office Action on the merits. Applicant must 
submit a complete listing of all the claims, as per 27 C.F.R. 1.121. 

Claim Rejections - 35 USC §112 

The text of those sections of Title 35, U.S. Code not included in this action can 
be found in a prior Office action. See also Response to Arguments - 35 USC § 1 12 
Rejection, below. 

Claims 20, 29 and claims dependent thereon are rejected under 35 U.S.C. 112, 
second paragraph, as being indefinite for failing to particularly point out and distinctly 


Application/Control Number: 09/241 ,188 Page 4 

Art Unit: 3625 

claim the subject matter which applicant regards as the invention. The claims refer to 
"key object classes" "secondary object classes" and that the "key object classes" 
partition the database in accordance with high-level category. The term is indefinite 
because the specification does not clearly redefine the term, and applicants appear to 
use the term as synonyms. 

Where applicant acts as his or her own lexicographer to specifically define a term 
of a claim contrary to its ordinary meaning, the written description must clearly redefine 
the claim term and set forth the uncommon definition so as to put one reasonably skilled 
in the art on notice that the applicant intended to so redefine that claim term. Process 
Control Corp. v. HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. 
Cir. 1999). While applicant may be his or her own lexicographer, a term in a claim may 
not be given a meaning repugnant to the usual meaning of that term. See In re Hill, 161 
F.2d 367, 73 USPQ 482 (CCPA 1947). 

The term "key" and "key object class" in claims 20 and 29 are used by the claim 
to mean "a class of objects that contain keys", while the accepted meaning is "A key 
(key field) is an identifier for a record or group of records in a data file. In database 
design, an index is a list of keys (or keywords), each of which identifies a unique record. 
Indices make it faster to find specific records and to sort records by the index field, that 
is, the field used to identify each record. 1 A partition is a logically distinct portion of 


1 Definition of Index, RANDOM HOUSE WEBSTER'S Computer and Internet Dictionary. 
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memory or a storage device that functions as though it were a physically separate unit; 
In database programming, a partition is a subset of a database table or file. 2 " 

The terms "key", "key object class" "secondary object class" will be given their 
broadest reasonable interpretation to read on a field that serves as a reference to data, 
such as a customer identification number, that is used to reference customer data such 
as a customer's address, telephone number, etc. A secondary object class will be 
interpreted to read on data related to an additional classification of data in a database. 


Claim Rejections - 35 USC § 103 

The text of those sections of Title 35, U.S. Code not included in this action can 
be found in a prior Office action. 

Claims 20-23, 25-27 and 29-35 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Schein et al. U.S. Patent 6,226,623 in view of Owens et al. (US 
Patent 6,047,267). 

As noted above, "key", "key object class" "secondary object class" will be given 
their broadest reasonable interpretation to read on a field that serves as a reference to 
data, such as a customer identification number, that is used to reference customer data 
such as a customer's address, telephone number, etc. A secondary object class will be 
interpreted to read on data related to an additional classification of data in a database. 
Prior art will be interpreted to read on applicants' claims where prior art discloses one or 
more fields that organize data into categories. Prior art will be interpreted to read on the 


2 Definition of Partition, MICROSOFT Computer Dictionary. 
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claims where prior art discloses the use of database fields to identify customers and 
customer relationships to providers of financial services. 

Schein discloses a system and methods for creating and facilitating a plurality of 
stored value products, the system comprising: 

(a) a plurality of client systems each of said client systems being associated with at 
least one of the plurality of stored value products (Schein discloses that banks 
offer additional products or services and that customers may open accounts (i.e., 
Schein creates and facilitates plurality of financial products, including stored 
value products) see at least 4, lines 23-44). Schein describes a plurality of 
stored value products associated with a CITIBANK client system; Schein 
discloses that brokerage firms such as MERRILL LYNCH also participate in 
offering financial products such as CITIBANK'S; Schein discloses that VISA 
CORPORATION may also use their invention (see at least Col. 6, lines 6-67, Col. 
21 , lines 37-63) and that various other financial institutions and networks and 
participants of those networks may use their invention (Col. 22, lines 4-16). 

(b) database facilitating the storage and retrieval of customer data, merchant data, 
and a plurality of data items (see at least, Col. 9, lines 42-47; see also references 
to centralized databases, Col. 10, lines 41 -Col. 11, line 20); 

(c) a transaction capture module configured to receive transaction data from a point- 
of-sale terminal configured to [receive] accept at least one of said plurality of 
stored value products (see at least, Col. 10, lines 41-56; Col. 20, lines 51-67; Col. 
20, lines 51-67); and 
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(d) a database server configured to support [each of] said stored value products, to 
receive said transaction data from said transaction capture module, and to route 
said transaction data among said plurality of stored value products executing on 
said plurality of client systems; (see at least, Col. 9, line 62-Col. 10, line 7; see 
also at least references to multiple-user databases sharing of information and 
resources, Col. 7, lines 12-34; see references to location of various databases, 
including centralized data storage, and communication with various client 
systems that store and supply data to a centralized site, Col. 10, lines 41-56); 

(e) wherein each of said stored value products comprises a plurality of data items 
retrieved from said database (see at least, Col. 7, lines 13-33, describing service 
providers, financial institutions, their products, including stored-value products), 

(f) wherein each of said plurality of data items provides a function that is available to 
each of the plurality of stored value products [such that]; and wherein each of 
said plurality of stored value products is allowed to retrieve said customer data 
and said merchant data from said database using at least a portion of said 
plurality of objects (see at least, Col. 10, lines 41-56; see also at least references 
to profiles stored in a single repository, Col. 10, lines 28-Col. 1 1 , line 48). 
Schein discloses a report generating system in communication with a database 

server, wherein the report generating system is configured to assemble reports based at 
least in part upon said transaction data (see Col. 6, lines 53-65). Schein discloses an 
authorization server in communication with the database server and the point-of-sale 
terminal and wherein the point-of-sale terminal is configured to query the authorization 
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server for transaction approvals (see at least, Col. 2, lines 7-17; Col. 22, lines 4-24; Fig. 
13, Fig. 2, items 28, 46; Col. 3, lines 53-63. Schein discloses a plurality of data items 
comprising consumer information that is available to each of a plurality of stored value 
products (see at least, Col. 10, lines 41-56). 

Schein discloses a server facilitating the operation of a plurality of stored value 
programs, each of said stored-value programs being associated with one of a plurality 
of client systems, the server comprising: 

(a) a digital computer in communication with a database maintaining consumer 
information, merchant information and a plurality of data items (see at least, Col. 9, 
line 42-Col. 10, line 7); 

(b) wherein each of said plurality of data items is configured to facilitate a particular 
function and to associate with each of said plurality of stored value programs (see at 
least, Col. 7, lines 13-33, describing service providers, financial institutions and their 
products), and 

(c) wherein each of said plurality of stored value programs accesses said consumer, 
information and said merchant information via at least one of said plurality of data 
items (see at least, Col. 10, lines 41-56); 

(d) such that said consumer information and said merchant information is available to 
each of said plurality of financial products through a common interface available 
from the plurality of client systems, (see description of a common interface called a 
Global Integration Facility/GIF Col. 14, lines 36-51; see also references to client 
systems sending information to a centralized system, Col. 10, lines 28-65). 
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Schein discloses a method of facilitating financial transactions at a server, the 
method comprising the steps of: 

(a) selecting a first plurality of objects from a repository of objects to form a first 
stored value program, said first stored value program corresponding to a first 
financial product and being associated with a first client system (see at least Col. 

3, line 65-Col. 6, line 65 for description of the art related to forming a first stored 
value program and its corresponding financial product; Col. 4, lines 39-5Col. 11, 
lines 11-48; Col. 12, lines 21-49 describing linking of various customer accounts 
and financial products; see also claim 20, above); 

(b) selecting a second plurality of objects from said repository of objects to form a 
second stored value program, said second stored value program corresponding 
to a second financial product and being associated with a second client system 
(see at least Col. 3, line 65-Col. 6, line 65 for description of the art related to 
forming a first stored value program and its corresponding financial product; Col. 

4, lines 39-5Col. 11, lines 11-48; Col. 12, lines 21-49 describing linking of various 
customer accounts and financial products); and 

(c) accessing a database comprising consumer information and merchant 
information by said first and second client systems such that said first and 
second stored value programs interact with said database via said first and 
second pluralities of objects, respectively, to implement said first and second 
financial products on said first and second client systems, respectively (see at 
least Col. 7, lines 13-33; Col. 10, lines 41-56; see also utilization of common 
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reports and customer demographic information available from stored objects that 

are created by any client system, Col. 10, lines 66-Col. 1 1 , line 34). 

Schein discloses receiving a transaction request from a point of sale terminal, 
said transaction request corresponding to one of said financial products (see at least 
Col. 10, lines 41-56, Col. 15, lines 41-52; Col. 20, line 51-Col. 22, line 3). 

Schein discloses determining a financial product corresponding to a transaction 
request at a transaction server, and further comprising a step of processing a 
transaction request in accordance with a first (or nth) plurality of data items if a 
transaction request corresponds to a first financial product (or nth). See at least, Col. 
10, lines 41 -Col. 12, line 49, describing the types of information available from the 
database. The information on the database is available for each transaction, and the 
transaction request is linked to a customer's products. A customer may have many 
products, each product associated with an object. These data items may also be 
referred to as a first through nth product. 

Schein discloses separating a first and second financial product based upon a 
key value where said key value corresponds to a business unit, (see at least, Col. 5, 
lines 5 -Col. 67; Col. 6, line 7-Col. 7, line 46; Col. 10, lines 41- Col. 11, line 10 describes 
Database Management Systems. Database systems rely on unique and non-unique 
keys to store and access information. A key may identify CITIBANK, see at least, or a 
key may identify the CMMA CITIBANK MONEY MANAGEMENT ACCOUNT, as a 
separate business unit, if desired). 
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In summary, Schein discusses all limitations of applicants' invention, including 
stored value products such as smartcards and ATM cards. Client system computers 
may be connected to servers via the Internet (see at least Fig. 3, and Col. 15, line 53- 
Col. 16, line 7, Col. 21, lines 4-36; Col. 9, lines 57-Col. 10, line 7). Schein mentions 
several types of persistent repository mechanisms, including DB2, ORACLE (Col. 9, 
lines 1-67; see also application, page 17, lines 16-3). Schein discloses that other data 
models and structures may be applied (see at least Col. 6, lines 7-45, profiles and data 
models) and points out problems that arise when several sections in one or more clients 
maintain application-specific data and programs (see at least Col. 6, lines 25-44). 
Classes and objects are another way of modeling & data in persistent storage. 

Schein does not use the words class and objects to specifically disclose: 

...[first plurality of] objects.. .a first stored value program... 

...objects being instances of a secondary object class derived from a key object 

class... 

... key object classes. . . secondary classes. . . derived from said key object 
classes... 

...[second plurality of] objects... 
...second stored value program(s)... 

...[database]... such that said first and second stored value programs... interact 
with... [database]... via ... first and second pluralities of objects 

As admitted by applicant, these words are found when one uses a data model 
called the "object-oriented" model. Owe/is discloses the use of relational databases in 
an object-oriented design in a multi-product on-line and Internet environment (see at 
least Abstract, Col. 1, lines 1-Col. 2, line 60, Col. 5, lines 36-Col. 7, line 30). Owens 
discloses a system for administering a plurality of financial resources in an object- 
oriented paradigm where persistent storage takes place in relational database 
management scheme (see at least references to SQL, the Structured Query Language 
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that is used to access relational databases, Col. 1, lines 19-60). Owens describes 
systems and methods for a system architecture that includes relational database 
information may be implemented in an object-oriented paradigm (see at least Col. 5, 
line 35-Col. 6, line 10). 

It would have been obvious to one of ordinary skill in the art of electronic- 
commerce to combine Schein and Owens to apply an object-oriented paradigm and 
describe plurality of financial products in terms of plurality of classes and plurality of 
objects. One of ordinary skill in the art of electronic-commerce would have been 
motivated to combine Schein and Owens to apply an object-oriented paradigm and 
describe plurality of financial products in terms of plurality of classes and plurality of 
objects for the obvious reason that the use of object oriented paradigm to describe data 
and interactions among data provides a more modern technique of how data interacts 
with business applications. Applying object-oriented terms permits one of ordinary skill 
in the art to reuse program code (classes) by instantiating a class into one or more 
objects that correspond to data items retrieved and used by different sub-systems. 

The information on the centralized database is available to each of the client 
system databases for each transaction, and the transaction request is linked to a 
customer's products. In an object-oriented world, a customer may create (open/add/ 
insert or other term) one or more financial product, including stored value products, and 
each product may be associated with an object. This plurality of objects may also be 
referred to as a first, second, through nth product, just as the plurality of client systems 
may be referred to as a first client system, a second client system, etc.). 
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While both Schein and Owens disclose the use of databases and key fields to 
partition and organize databases, Schein and Owens do not specifically refer to "key 
object classes" and "secondary object classes." However, it was well known, at the time 
the invention was made, to partition databases and include key (index) fields to 
organize data. Therefore, it would have been obvious to one of ordinary skill in the art 
at the time the invention was made to include keys/indexes, key object classes and 
secondary object classes. One of ordinary skill in the art at the time the invention was 
made would have been motivated to include keys/indexes, key object classes and 
secondary object classes for the obvious reason that having references to data (such as 
keys, indexes, key object classes and secondary object classes) permits faster access 
of data and cuts down on wait time for customers. By cutting down search and access 
time, service providers may well retain customers, since customers usually do not enjoy 
waiting. When customers are forced to wait, customers may decide not to continue 
patronizing financial service providers, and may take their business elsewhere. One 
might also provide for the use of Key object classes, for example, when a search has all 
the key fields, possibly down several levels in a hierarchy. This type of 00 design also 
permits rapid access to data and may assist in retaining customers. 

Response to Amendment 

In their amendment of 15 December 2003, Applicant amended claims 20 and 29 
and cancelled claim 28. 

Claims 20-23, 25-27 and 29-35 remain and are examined. 
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Response to Arguments 35 USC §112 Rejection 

Applicant's arguments concerning the rejection under 35 U.S.C.1 12 have been 
fully considered but they are not persuasive. 

Applicant argues that the terms key object classes and secondary object classes 
are clearly described in the specification. 

The Examiner respectfully submits that Applicant's comments are not responsive 
to the rejection of "key object class" as indefinite for failing to particularly point out and 
distinctly claim the subject matter which applicant regards as the invention. As correctly 
noted by Applicant, the Examiner argued that key object classes "...are not clearly [re-] 
defined in the specification.. .applicants appear to use the terrors synonymously..." 

key object classes 

For a description of "key object classes," see, for example, page 18, line 13 ("(database 
142 preferably contains a 'key field that partitions the database according to a high-level 
class of objects") followed by the "business unit" class example (page 18, line 16), which 
is used to organize the data into useful business-related partitions. As the specification 
notes, the key fields, which partition objects classes, can be used to "organize database 
142 in radically different fashions" (page 18, line 18). Some additional examples of key 
object classes (and the resulting logical partitions) include geographic region (page 18, 
line 20) and product classes (page 18, line 21). Page 19, lines 1-7, describes key object 
class inheritance. Page 19, lines 8-18 describes how firewalls can be used for logical 
separation of objects on a single database. Figure 7 further illustrates the use of these 
"key object classes." 

The Examiner respectfully notes that the term "key object class" appears twice in 
the original specifications and is not defined: 

Database 142 preferably contains a "key" field that partitions the database 
according to a high-level class of objects. An example of a "key" field is the 15 "business 
unit" class 188 shown in Figure 7. In the exemplary embodiment shown in Figure 7, the 
"business unit" class 188 organizes the database into partitions corresponding to, for 
example, a company organizational structure. Alternate embodiments of the invention 
organize database 142 in radically different fashions by using differing key fields. For 
example, the key could be 20 used to logically separate database 142 according to 
geographic region (e.g. "North America", "Europe" and "Asia"), or according to product 
classes (e.g. "Smartcard", "ATM card", "Internet account" and the like), or according to 
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any other suitable differentiator. Key object class 188 substantially defines many of the 
default values for various dependent classes because objects depending from key 
object class generally inherit substantially all of the attributes and functions defined for 
the parent class. In an embodiment that uses "business unit" as a key class 188, for 
example, all database objects that reside in the same business unit generally share 
common default currencies, languages, product details, address masks and the like, 
(originally filed application, page 18, lines 13-page 19, line 7). 

Applicant introduced the term key object class into claims 20, 28, 29 with his 
Request for Continuing Examination of 28 May 2003. Reference 188 identifies (a) key 
object class, (b) key class, (c) key field, e.g., "business unit class 1 88" key field, further 
confusing the issue. 

Concerning secondary object classes, applicant comments include 

secondary object classes 

For a description of "secondary object classes," see page 19, line 19, where the 
specification explains that "secondary classes 186 generally depend from the key class 
1 88" This is clearly illustrated in Figure 7. Page 20, lines 3-6 gives an example where 
"secondary object class 1 86 differentiates various product belonging to the same key 
class 188" Page 20, lines 7-20 set forth a further example useful in a smartcard context. 
Page 21 , lines 2-4, contrasts key classes and secondary class. Page 21 , lines 6-9 
describes how key objects and secondary objects effectively share and re-use objects 
stored in the repository. Page 21, lines 12-15 also clearly notes the difference between 
key objects and secondary objects. 

The Examiner respectfully notes that the term "secondary object class" appears 
once in the original specifications while "secondary class" appears 4 times. Neither 
term is defined. Reference 1 86 refers to different items, further confusing the issue: (a) 
secondary class, (b) secondary object class, (c) "products" class, (d) secondary 
"product" class, (e) product object, (f) secondary objects, (g) stored value products 186. 

The Examiner respectfully notes that Applicant also contradicts himself. On one 
hand, the Applicant agues 

...The Examiner addresses this terminology on page 1 8 of the Office Action. Certainly, 
the term "object" is used in the present application in its traditional sense of an 
instantiation of an "object class." 


Then, Applicant states: 
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...But the terms "key object class" and "secondary object class" (and their respective 
objects) are used differently in the present application. Specifically... [repeats claim 
language] 

The Examiner also respectfully notes that Applicant's arguments are directed to 
his use of key object class and secondary object class in the application in the context 
of object oriented design. The rejections under 35 USC § 1 12 are directed at the 
language of the claims, where Applicant attempts to use the terms as synonyms for 
database keys and indices. 

In response to applicant's argument that 

This element, which improves efficiency and object re-use in the design and creation of 
stored value products, is not suggested, inferred, or otherwise disclosed by any 
combination of the art of record. 

the fact that applicant has recognized another advantage which would flow 
naturally from following the suggestion of the prior art cannot be the basis for 
patentability when the differences would otherwise be obvious. See Ex parte Obiaya, 
227 USPQ 58, 60 (Bd. Pat. App. & Inter. 1985). 

Applicant's arguments and Applicant's fleeting mention of "object oriented" in the 
same sentence as the word "database" do not overcome the rejection of claims 20, 29 
and their dependent claims as indefinite. 

Response to Arguments - 35 USC § 103 Rejection 

Applicant's arguments concerning the rejection under 35 U.S.C.103 have been 
fully considered but they are not persuasive. 

Applicant argues 

...applicants restate their argument that neither of the cited references include a system 
which includes objects that are [...limitations of amended claims...] and wherein are 
[...limitations of amended claims...] as recited in the claims as amended. 
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In response to this argument, please see rejection above. The Examiner 
also respectfully notes that applicants' arguments were raised and answered in 
previous Office Actions. Nevertheless, the Examiner will take this opportunity to 
further elaborate on the rejection and to further clarify the record, and so that 
applicants may more easily identify particular features of their invention that are 
unpatentable over Schein, Owens and knowledge generally available to those of 
ordinary skill in the art. 

Applicant argues 

[...Owens...] does not disclose the specific use of a secondary object that inherits its 
characteristics from a key object class and which is itself a stored value product. It is the 
combination of this object architecture, in combination with the use of multiple stored 
value products, that is central to the invention. 

In response to this argument, the Examiner notes that the term inherit does not 
appear in the rejected claims. Further, in response to applicants' arguments against 
Owens individually, the Examiner again respectfully notes that one cannot show 
nonobviousness by attacking references individually where the rejections are based on 
combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 
1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). 

No combination of Schein, Owens, or the general prior art attributable to someone of 
ordinary skill would include the system as recited in the amended claims. 

Again, Schein discloses applicants' invention but does not address issues of 
object-oriented analysis and design. Owens was first introduced in a parent application 
[09/105406, now abandoned]. Owens was re-introduced in the present application to 
address applicants' concern over the absence of the word object in Schein. 
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Owens is used to show that object-oriented paradigms and their application to 
database technologies are (a) old and well known, (b) may be used in many types of 
computer applications and software design, and (c) may be used particularly with 
financial products such as claimed by applicants. For purposes of definitions, object 
technology is the use of objects as building blocks for applications. 3 An object is a self- 
contained module of data and its associated processing. 4 Applicants have not shown 
that their use of object-related terminology (e.g., object, object-oriented analysis, object- 
oriented design, etc.) differs from the terms' widely accepted use. 

Owens combines client-server nomenclature, object-oriented terminology in a 
financial environment that includes various types of financial products from one or more 
clients and one or more client systems (see at least Col. 5, line 36-Col. 6, line 10). As 
noted above, Applicants have not argued or shown that their use of the terms "smart 
card" "bank" "stored value product" varies from the common ordinary meaning of the 
terms, and as found in Schein and Owens. 

In response to applicant's argument that the references fail to show certain 
features of applicant's invention, the Examiner respectfully notes that the features upon 
which applicant relies (i.e., complication and complexity of a database, intricate backend 
transaction processing system, "...element, which improves efficiency and object re-use 
in the design and creation of stored value products...") are not recited in the rejected 
claim(s). Although the claims are interpreted in light of the specification, limitations from 


3 The Computer Desktop Encyclopedia, Alan Freedman, copyright 1996. 

4 The Computer Desktop Encyclopedia, Alan Freedman, copyright 1996. 
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the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1 181 , 26 
USPQ2d 1057 (Fed. Cir. 1993). 

A "traverse" is a denial of an opposing party's allegations of fact. 5 The 
Examiner respectfully submits that applicants' arguments and comments do not 
appear to traverse what Examiner regards as knowledge that would have been 
generally available to one of ordinary skill in the art at the time the invention 
was made. Even if one were to interpret applicants' arguments and comments 
as constituting a traverse, applicants' arguments and comments do not appear 
to constitute an adequate traverse because applicant has not specifically 
pointed out the supposed errors in the examiner's action, which would include 
stating why the noticed fact is not considered to be common knowledge or well- 
known in the art. 27 CFR 1.104(d)(2), MPEP 707.07(a). An adequate traverse 
must contain adequate information or argument to create on its face a 
reasonable doubt regarding the circumstances justifying Examiner's notice of 
what is well known to one of ordinary skill in the art. In re Boon . 439 F.2d 724, 
728, 169 USPQ 231, 234 (CCPA1971). 

If applicant does not seasonably traverse the well known statement during 
examination, then the object of the well known statement is taken to be admitted prior 
art. In re Chevenard, 139 F.2d 71, 60 USPQ 239 (CCPA 1943). MPEP 2144.03 
Reliance on Common Knowledge in the Art or "Well Known" Prior Art. In view of 


5 Definition of Traverse, Black's Law Dictionary, "In common law pleading, a traverse signifies a denial." 
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applicant's failure to adequately traverse official notice, at least the following are 
admitted prior art: 

...use of objects and classes to describe data allows a clearer view of how data interacts 
with business applications. Applying object-oriented terms permits one of ordinary skill in 
the art to reuse program code (classes) by instantiating a class into one or more objects 
that correspond to data items retrieved and used by different sub-systems. 

The information on the centralized database is available to each of the client system 
databases for each transaction, and the transaction request is linked to a customer's 
products. In an object-oriented world, a customer may create (open/add/insert or other 
term) one or more financial product, including stored value products, and each product 
may be associated with an object. This plurality of objects may also be referred to as a 
first, second, through nth product, just as the plurality of client systems may be referred to 
as a first client system, a second client system, etc.). 

...it was well known, at the time the invention was made, to partition databases and 
include key (index) fields to organize data. 

...having references to data (such as keys, indexes, key object classes and secondary 
object classes) permits faster access of data and cuts down on wait time for customers. 
By cutting down search and access time, service providers may well retain customers, 
since customers usually do not enjoy waiting. When customers are forced to wait, 
customers may decide not to continue patronizing financial service providers, and may 
take their business elsewhere. One might also provide for the use of Key object classes, 
for example, when a search has all the key fields, possibly down several levels in a 
hierarchy. This type of 00 design also permits rapid access to data and may assist in 
retaining customers. 


Conclusion 

Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 
§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
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shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to James H Zurita whose telephone number is 703-605- 
4966. The examiner can normally be reached on 8a-5pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Jeffrey A. Smith can be reached on 703-308-3588. The fax phone number 
for the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 

Patent Application Information Retrieval (PAIR) system. Status information for 

published applications may be obtained from either Private PAIR or Public PAIR. 

Status information for unpublished applications is available through Private PAIR only. 

For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 

you have questions on access to the Private PAIR system, contact the Electronic 

Business Center (EBC) at 866-217-9197 (toll-free). 

James Zurita 
Patent Examiner 
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